Rationale behind the feature

Currently, the methods of the Authentication API client return a Request value. Since it’s a struct, it’s not really mockable. This makes it harder to test the (native) bridge code of those SDKs that wrap around Auth0.swift, like auth0-flutter –including any custom wrappers our customers write.

Till now to mock the Auth0 SDK layer, developers had to use URLProtocol to mock URLSession for writing unit tests on the client app or wrapper SDK. With the Requestable protocol, developers can now do not have to do the heavy lifting of mocking URLSession for writing unit tests. It makes it super easy.

This PR promotes Requestable to the primary request interface across the SDK, so API clients return any Requestable<T, E> instead of Request<T, E>, improving ergonomics around mocking/testing and enabling existential-friendly chaining plus async/await and Combine support.

Changes:

1. Update public client protocols + concrete implementations to return any Requestable<..., ...> instead of Request<..., ...>.
2. Expand Requestable to include builder methods plus async/await and Combine start() overloads; adjust Request builder return types accordingly.
3. Update internal JWKS request storage and adjust tests to work with protocol existentials.

Tests Updated

• Auth0Tests/MFA/Auth0MFAClientTests.swift — 13 local variable type annotations changed from let request: Request<T, E> to let request: any Requestable<T, E>.
• Auth0Tests/AuthenticationSpec.swift — Added a private extension Requestable that exposes dpop: DPoP? via a conditional downcast to Request<T, E>, allowing DPoP-related test assertions to continue working on any Requestable<T, E> values without polluting the public API.
• Auth0Tests/RequestSpec.swift — Tests that verify the stored parameters, headers, and dpop properties after calling a builder method now cast the builder result back to Request<T, E> (e.g. as! Request<[String: Any], AuthenticationError>) before inspecting internal state. These tests are specifically exercising Request<T, E> internals, so the explicit downcast makes the intent clear.
• Tests added for sample app ContentViewModel demonstrating usage of Requestable protocol for mocking

Migration Impact

Source-breaking for callers who store the return value with an explicit Request<T, E> type annotation. All other usage patterns (chaining, start {}, try await .start(), Combine .start()) remain unaffected.

// Before — explicit type annotation:
let request: Request<Credentials, AuthenticationError> = auth.login(...)

// After — use the protocol type or rely on type inference:
let request: any Requestable<Credentials, AuthenticationError> = auth.login(...)
// or simply:
let request = auth.login(...)